feat(ios): make CoreSVG decoder opt-in - #606

Hey @oleksandrzavarzin-callstack, thanks for picking this up from #566. The codegen, modulemap and SPM work is solid. I'm asking for a change of direction on two points, plus a few smaller findings.

1. Let's not ship a breaking change now

Keep SVG enabled by default in this release, and make disabling it the opt-in. Flipping the default should wait for the next major.

Suggested shape: a single tri-state flag, so the next major doesn't need a new one:

Please flag the upcoming change in these places:

• Pod::UI.warn during pod install when the flag is unset, e.g. "SVG tab icons will be disabled by default in the next major. Set $RNBottomTabsEnableSVG = true to keep them, or false to drop the private CoreSVG code now."
• A deprecation callout in the docs section.
• Make the changeset minor, and mention the upcoming default change in its note.
• A TODO(next major) next to the default in svg_configuration.rb and Package.swift.

2. <Image> SVGs must keep working

On main, SvgDecoder is registered as a global RCTImageDataDecoder, so any <Image source={...svg}> in a consumer app works because of this library. This PR scopes the decoder to tab icons only, which silently breaks those images even with the flag on. We can't break unrelated parts of someone's app as a side effect. When SVG is enabled, the behavior must stay exactly what it is on main.

Since codegenConfig is static, I'd suggest:

• Keep the modulesConformingToProtocol registration, and keep SvgDecoder always compiled.
• Gate only the private parts (the body of CoreSVG.mm, the base64 strings, the dlsym calls) behind RN_BOTTOM_TABS_ENABLE_SVG. When disabled, canDecodeImageData: returns NO.
• Don't drop the class itself while the registration stays. RCTTurboModuleManager -moduleForName: calls RCTLogError(@"Unable to find module for %@") on lookup failure, which is a red box in dev.

With SVG disabled, the binary then has no private API references and no base64 literals, only a no-op SvgDecoder. That addresses #565's actual concern.

This also lets us drop SVGIconLoader and the TabViewProvider changes entirely, since RCTImageLoader decodes SVGs again. That resolves findings 3 and 4 below. The example app changes that replaced SVG icons with PNGs can be reverted too.

Other findings

1. Silent failure when SVG is disabled. If a tab icon is an SVG, the only signal is a Swift print, which never reaches Metro or LogBox. Please add a dev-mode RCTLogWarn that points to the flag. This matters more once the default flips.
2. CI only builds one configuration. No job builds the non-default side of the flag, so that code can rot unnoticed. Please add a CI variant for it, for both CocoaPods and SPM.
3. The fallback refetches every failed image (moot if SVGIconLoader goes away). With the flag on, any RCTImageLoader error (404, offline, a custom scheme) triggers a second download through URLSession.
4. SVG requests bypass RN's network stack (moot if SVGIconLoader goes away). They skip RCTImageLoader's cache, custom RCTImageURLLoaders and request handlers, and network inspection.
5. The flag check is too strict. The podspec only accepts == true, so '1' or 'true' are silently ignored. With the tri-state, explicit false also needs handling. Consider having the podspec read ENV['RN_BOTTOM_TABS_ENABLE_SVG'] too, so CocoaPods and SPM share one mechanism.
6. The bridging header edit does nothing. react-native-bottom-tabs-Bridging-Header.h isn't wired into the podspec and is excluded in Package.swift.
7. The Expo plugin uses a deep import (minor). @expo/config-plugins/build/utils/generateCode is an internal path, and mergeContents throws if a custom Podfile has no platform :ios line.